Do PMs need to have a technical background?#

Another “management-type” position that engineers often move into is product management (PM). Depending on who you survey, anywhere between 24% and 66% of PMs were previously developers. Ask anyone whether PMs need to have technical backgrounds, and you will get 600 words of “It Depends” dodging the question. You can code; that certainly does not hurt. Now, your task is to figure out whether product management is for you.

If you came into the tech world entirely via coding, PMs might seem like an odd breed of bullshit job from a distance. They show up every couple of weeks, tell everyone what to do, disappear to do god knows what, get mad when their meticulously color-coded Gantt charts run afoul of reality, and take credit for everything when stuff is shipped.

Mini-CEOs of the product#

I’m kidding. The variety of PM jobs and roles are even more diverse than EM roles if that is even possible. PMs are classically regarded as “mini-CEOs of the product,” entrusted with bridging the gaps between engineering, design, and business.

The classic PM Venn Diagram

History of product management#

Product management was created in 1931 at P&G, but the modern form of product management in tech owes its popularity to Marissa Mayer, pre-Yahoo, when she was a rockstar executive at early Google. Google wanted to cultivate “home-grown” managers who would be Googley, so the two-year Associate Product Manager program was created.

It spawned an entire generation of great tech leaders like Bret Taylor, who co-created Google Maps, served as CTO of Facebook, and is now President of Salesforce. Eric Schmidt has even gone on record saying an APM alum will run Google someday (This is not yet true; current CEO Sundar Pichai was a consultant before PMing for Chrome).

Given all this success, it is unsurprising that every tech company has some form of PM function (Microsoft calls it “Program Manager”). Having worked at a company that started with no PMs and eventually hired some, it is very reassuring to know that someone is herding all the cats and watching out for upcoming blockers and cross-dependencies.

Own the product#

Individual departments tend to get tunnel vision and view their problems as more important than others. Initially, founders serve as PMs, but as the company scales, founders have other things to do. So, sooner or later, they need to hire or promote product managers to “own the product.”

Know everything about the user persona#

For products that don’t serve developers (these are the vast majority of products), PMs also tend to be the primary user advocates or domain knowledge experts. Although UX/Design does user research, good PMs know everything about the user personas, right down to what competitor products they use and what kind of marketing channels work best for each.

They will also know when to ignore what research says. In a world of unambitious incremental improvements, PMs can serve as “visionaries” that can galvanize a company’s resources to create something that doesn’t yet exist.

PMs can serve as "visionaries"

“If I had asked people what they wanted, they would have said faster horses.”

- Henry Ford on the Model T (possibly apocryphal)

Product requirements documents#

PMs also used to write massive design specs called Product Requirements Documents that would lay out every detail of how the product was to behave (Therefore, a great amount of user research and some sense of engineering cost was required.). In these days of agile and lean development, PRDs were much leaner and sometimes even optional. Being able to code or mockup a quick MVP for user testing is much more desirable these days.

Product requirements documents

PMs don’t have authority#

PMs being PMs, every word of what I just wrote is hotly contested. PMs have all sorts of alternative Venn Diagrams to describe themselves and have written mountains of Medium posts on how they are Not the CEO of anything. The preferred framing these days is that PMs have “All of the Responsibility, and None of the Authority,” which makes you wonder how much sheer charm and begging PMs must subsist on to get shit done.

Product owner#

There is another type of “PM” that actually has little authority, called Project managers. The product manager (sometimes called the “Product Owner”) sets the vision for the product that needs to be built, gathers requirements, and prioritizes them, while the project manager acts upon this vision and makes sure that it is executed on time and on budget.

Set vision
[Not supported by viewer]
Gather requirements
[Not supported by viewer]
Prioritize tasks
[Not supported by viewer]
Product owner responsibilities

In small companies, product managers also serve as project managers. A poor or under-resourced “product manager” will functionally regress to project manager because it is the bare minimum needed to show life. However, the long-term value of bumping cells on a spreadsheet or playing calendar Tetris is not as high.

A personal anecdote#

Here, a personal anecdote is relevant. I spent a year as a non-technical product manager before deciding to change careers. Our startup had sixty devs, but each time I worked with a team to produce a new product feature, I noticed that the only people that got quality work done (and reasonably on time) were two devs.

Two out of sixty.

Of course, this was a highly dysfunctional dev team, but it resulted in any PM worth their salt fighting for these two devs’ time in order to get stuff done and playing project manager with the rest. When I got the job, I was sold on being a “mini-CEO,” but what I got was jockeying for position and weekly “is it done yet?” calls. That’s the kind of PM you don’t want to be. Eventually, I had enough and decided to become a developer myself. The PM to dev transition is rare, but I have started calling it “Team #FineI’llDoItMyself.” I hope you DON’T join us!

I'll do it myself

Merits#

The vast majority of PMs also don’t have unlimited license to “visionary” their way to implement any cockamamie idea. Usually, there is some direction from founders (Sometimes, too much!), and major projects have to be agreed upon at the board level. In other words, the job does involve a lot more “get things done” than “visionary” aspects in day-to-day reality, at least until you earn some amount of authority from your successful projects.

Demerits#

Overall, PMing can be a very rewarding post-coding career. If you have entrepreneurial ambitions or desire even more impact than in engineering management, the PM path is your best bet. PMs own product-level objectives and key results and often have the ear of the highest levels of leadership when critical goals are at stake. They may even own their product’s profit and loss (P&L), if attributable.

Products that have their own P&L also often run their own marketing; this tends to be such a specialized skill set that paired product marketing managers and technical product managers are common in BigCos. People who are particularly good at high-growth product marketing are known as Growth Hackers, a term coined by Sean Ellis and popularized by Andrew Chen. This is a great related discipline that talented coders should explore.

Note: PMs should care a great deal about everything we discuss in the Strategy section of this course!

Here are some recommended reads for those exploring the PM path:

Recommended reading

Engineering Management

Developer Relations